A portion of the disclosure of this patent document contains command formats and/or other computer language listings, all of which are subject to copyright protection. The copyright owner, EMC Corporation, has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The present invention relates to graphical user interfaces (GUIs) for use in computer systems and, more particularly, relates to a plug and play technique for manifesting a GUI in a manner which, among other things, enables its software developers to implement certain user-requested or otherwise-initiated GUI code changes up to runtime, and in a modular manner which does not impact other GUI code.
2. Description of Prior Art
As virtually all users of computer terminals have experienced, user-interaction with the computer, computer system, and/or computer network (including the Internet), in addition to keyboard interaction, generally involves positioning and activating a computer screen cursor, user-controlled by manually positioning a mouse and clicking its left and right mouse buttons. This mouse-cursor “subsystem”, through operation of software including user interface software (or “framework”), permits users to activate a computer screen framework of menus, buttons, dialog boxes, toolbars, etc. The activity resulting in this framework information and other computer-screen-displayed information derived from this framework can be defined as the GUI.
In GUI software development in the prior art, typically the code for operations is directly embedded into the message handler code that many user interface frameworks generate for menus, buttons, etc. Such code is compiled and linked into the overall application code module and is shipped to the customer-user in one unit. There are two main problems with this approach: (1) All code needed for the application is resident within a single module and has to be compiled and linked together. For large applications this can lead to long development times. Bug fixes in one part of the code can affect other parts of the code because there is no establishment and enforcement of boundaries between different parts of the code. (2) It is virtually impossible to add functionality on an as-needed or as-requested basis, during the development cycle or thereafter in response to developers' or users' desires, without recompiling, relinking, retesting, and reinstalling a great deal of functionally-unrelated code that should not have been affected at all by the added functionality. This is a very costly, time consuming, and wasteful repetition of code development, further running the risk of causing damage to code already in place. This is not an efficient manner in which to conduct software development.
Accordingly, software developers of complex software would like the flexibility to easily make changes to their software to effect GUI changes, in both software already supplied to users and in software still under development, without disrupting major portions of code already developed and finalized. In other words, they would like to be able to easily alter the software, which, in turn, alters the screen presentation or format, and they would like to be able to do this at any time, including after its shipment to a customer. Additionally, certain users such as, for example, major corporate purchasers of computer systems and equipment would like the flexibility to update or change available features or capabilities of GUIs supplied with their computer systems because their corporate needs change in response to their changing business conditions. This flexibility tends to be more difficult to achieve, however, as computer system performance requirements and expectations increase, whereby the software being developed, including GUI software, necessarily becomes more and more complex.
One approach that software developers have taken to simplify the software development process involves their use of object-oriented languages, such as C++ and JAVA, in writing their code. Briefly, an object, in computer software terms, is a dedicated area of memory which can be thought of as an impervious container holding both data and instructions within itself, both defining itself and its relationships to other objects in the computer system or network. An object or node can send and receive messages to and from other objects, respond and react to such messages (e.g. commands) but shall normally be impervious to internal scrutiny. For example, in a storage system (a kind of computer) each object (system object) may describe or relate to a specific tangible detail in the storage system or its processor (e.g. a fan, power switch, cache memory, power supply, disk drive interface, etc.), where these tangible objects in the storage system can send messages to each other and to other objects outside the storage system. The relationship between these specific objects in the storage system is usually visualized or characterized as a “tree” of objects. In a tree, each such object hangs off a preceding object as if in a parent-child or inheritance relationship, with many children hanging from a parent not being an atypical configuration. In addition to these tangible kinds of objects, logical units (LUNs) are other nodes or objects that can be contained within the tree. For example, a storage system object can have several LUN objects as its children which, in turn, can have various disk objects as their children, etc. These kinds of objects are generically referred to herein as “system objects” since they all relate to a system or to components within a system, whether it is a storage system, computer system, disk drive system, or some other system, and representations of these objects are typically displayed on the GUI in this tree fashion. However, other kinds of objects can also be formulated which do not relate to a system or its components per se, such as objects relating to user actions and represented on the GUI in other ways. (User actions are any commands or operations initiated by the user, such as, for example, creating a LUN or downloading new software to a disk, etc.)
Another prior art approach to simplification in software development, in general, involves the concept of modularity, where software, whether object-oriented or otherwise, having common or related functionality is grouped together for control purposes. A first group then communicates with other functionally-unrelated groups of software through well-defined interfaces. This modular approach has resulted in certain notable efficiencies. In this approach, developers are organized into appropriate teams corresponding to the various groups, thus allowing parallel development. Also, this approach allows software development to proceed in a manner in which a particular group's software can be modified without negatively impacting other groups' software. However, this approach does not address inefficiencies noted above with regard to code modification after completion of the development cycle or after shipment to a customer user.
These shortcomings and inefficiencies of prior art techniques of software development, and particularly as relating to GUI software development are addressed and overcome by the welcome arrival of the present invention.